The recording of sound tracks has, in the past, been accomplished by analog devices such as tape recorders. Editing of the sound recordings or sound tracks was conventionally accomplished mechanically by means by splicing tapes or by the recording or bouncing of sound tracks or portions thereof from one track or tape recorder to another, thereby making the editing changes during this process.
With the advent of analog-to-digital and digital-to-analog converters, digital signal processors, and the like being applied to the audio recording arts, efforts have been made to provide for capture and editing of the audio information while in digital form by means of various digital processing systems. One such system currently available is the Audio Visual Connection.TM. product available from the IBM Corporation, Armonk, N.Y., which takes the form of an audio peripheral adapter card for performing D/A and A/D of the audio data and installable in a conventional personal computer such as a PS/2 Model 50, and appropriate capture and editing software, both also available from the IBM Corporation (PS/2 is a registered trademark of the IBM Corporation). The accompanying documentation to such a system describes in greater detail the components and operation thereof and the information contained in such documentation is incorporated herein by reference.
Numerous digital systems have been provided for facilitating a user friendly interface and system for effecting editing of digitized audio data under control of a personal computer. Among these are the systems and interfaces disclosed in the following references which are herein incorporated by reference. "Basic Editing Functions for a PC Audio Editor, IBM Technical Disclosure Bulletin, Vol. 30, No. 12, May 1988; "Screen Format for a Basic Audio Editor", IBM Technical Disclosure Bulletin, Vol. 31, No. 9, February 1989; "Display of Audio Signal Processor Setup (Hook Up) for a PC Audio Editor", IBM Technical Disclosure Bulletin, Vol. 30, No. 10, March 1988; "Creation/Modification of the Audio Signal Processor Setup for a PC Audio Editor", IBM Technical Disclosure Bulletin, Vol. 30, No. 10, March 1988; "Audio Object Structure for PC-Based Digital Audio", IBM Technical Disclosure Bulletin, Vol. 30, No. 10, March 1988; "Single Display Panel Structure for a PC Audio Editor", IBM Technical Disclosure Bulletin, Vol. 30, No. 10, March 1988; and "Audio Editor System", IBM Technical Disclosure Bulletin, Vol. 30, No. 12, May 1988.
The digitized audio data in such systems is conventionally stored in DOS/OS files having two major components: an audio data file and an index table into the file. Each index in the table represents the offset of the corresponding audio data in the file and points to an audio segment which is simply an addressable unit of audio. Each index table represents one track of audio and refers to a single audio file. In the playback of a sound, the audio index is typically traversed sequentially and the corresponding data from the audio file is read and sent to the aforementioned audio adapter card for processing and playback including conversion to analog form. Provision for such indexes provides many convenient capabilities, as, for example, in the simple repeating of an index in the table resulting in playback of the same physical audio segment multiple times.
When the user edits digitized audio information in the course of using such capture/editing systems, it is conventional for changes to made to the index table and not the actual audio data file itself. Only at the end of an editing session are changes made to the audio data file. Throughout the editing process the user may have deleted index entries (i.e., deleted sound), inserted new index entries (i.e., inserted new sound), or copies existing index entries (i.e., repeated a sound). After the editing process has been completed by the user, the audio data file must be updated to reflect the changes which have occurred in the edited index. Accordingly, if an index in the table has been deleted, although it will thus no longer exist in the table, the corresponding digitized audio data will still remain in the file. As digitized audio files of any practical length typically occupy rather large quantities of computer memory, and as this memory space, due to cost factors, is often at a premium, it is essential to recover such space in a process referred to as a "resequence" or "garbage collection".
A resequence is essentially accomplished by traversing the edited audio index sequentially and copying each valid index's audio data to a new file. The original index table entry is thence modified to reflect the new offset in the target file. At the end of the resequence, the old file is deleted, and the new file receives the original file's name. In this way, if an audio segment in the original file does not have an index pointing to it, it will not be copied to the new file.
Repeated indexes which refer to the same physical audio segment in the original file will also be repeated and refer to the same physical audio segment in the new file. The first time an index is encountered during a resequence, its corresponding audio segment is copied to the new file. Each subsequent index which refers to this same sound will not cause another data copy, but its index will simply be reset to the new file offset location of the previously copied sound segment.
The original audio index table in the prior art is not actually updated to reflect the new offset position. Rather, a new audio table is created and updated to reflect the new file offset position. At the end of the resequencing procedure, the original audio index table is deallocated and the new table becomes the current table and acts as the index table into the new, resequenced file. The original audio index table and the new audio index table are related on a one-to-one basis of course. In this way, for any original index which has been copied over, its new file offset may be determined by simply consulting the new index table at the same position. In essence, then, a "look up" table of old file offsets/new file offsets is thereby created as audio data is copied over.
For each index in the original audio index table, it may be determined if the index's audio data has been already copied over to the new file. To do this, the current index is compared with each index which has already been copied over. If a match occurs with a previously copied index, this index's new file offset will be retrieved from the same position in the new audio index or "look up table". This index is then placed into the new audio index table at the position of the current index. In this manner, multiple indexes can point to the same physical audio segment or "sound".
The problem however with this approach in the prior art is that each index must be compared with every index which has already been copied over. As more indexes are copied over, the number of indexes to compare also grows. This can be extremely time consuming if there are a large number of indexes. Because the base operation of resequencing is a complete copy of the audio data file, the minimum time required for a resequence is at least the same amount of time required for a DOS copy. As indicated in the following Table 1, typical usage examples employing the aforementioned conventional system for garbage collection are shown:
SPEED TIMINGS TABLE 1 ______________________________________ IBM PS/2 Model 50 # of indexes file length DOS copy Resequence ______________________________________ 1) 4840 4.6 Meg 1:27 22:25 2) 4440 4.2 Meg 1:20 20:25 ______________________________________
It will be noted from the foregoing that the resequencing time required is substantially larger than that required for a DOS copy. However, it should be readily apparent that the times for resequencing should desirably approach the time for a DOS copy for the same file in order to be an acceptable solution and to provide for a practical audio editing system.
It would thus be highly desirous to provide a data processing application system for facilitating the editing of digitized data which substantially reduced the time required for resequencing in the editing process.